As someone who had quite some issues with Swift stdlibs version constraints (Apple really has a habit of not caring at all, unfortunately), from my experience, packages like this solve this issue quite well:

https://github.com/swhitty/swift-mutex

It's comparable to the backport you mentioned in your Pull Request, but more mature.

@Akazm I think it's the same (I found it in the one you mentioned at the bottom of the readme, the author is the same).
I've mentioned the gist and not the entire library because it might be easier to integrate in a library like async-algorithms avoiding an explicit third party SPM dependency.

thanks to @pyrtsa the branch is now passing tests properly on my end.
Waiting for @phausler and @FranzBusch feedback.

Just as a heads up, I haven't brushed over this - the implications here are pretty steep so this needs to be carefully considered. Backporting has some severe implications not just to the issues that already are addressed but to the process this package takes beyond just it being hosted here.

long/short please have patience with me while I check on a ton of other stuff (and note - those external requirements may have fallout to the proposed alternative here).

One thought that might have a better pan-out is leaving this as 1.1 but then altering 1.1 to have an earlier OS requirement and then posing a 1.2 for other algorithms.

Having this AsyncSequence throw unconditionally is a deal breaker of this backport IMO.

You would probably need some rethrows trickery to get this working. If this doesn't work I feel like the pitch needs to be updated as well and point that out.

@stefanomondino per the general concept of back porting share;

Here are the requirements to satisfy -

• When using the API in 6.2 it must support proper typed throws
• When using the API in pre 6.2 it must not be unconditionally always throwing the existental any Error aka Error type
• When using the API in 6.2 it must funnel through the isolated variation (that is a huge performance hit if not)
• the versioning of the framework must be 1.1 (if we land this the versioning will then be bumped beyond when requiring newer things); effectively we would be changing the baseline requirements of 1.1 to be a older OS release requirement than the just newly released macOS/iOS etc and 1.2 would then likely be for those requirements.

As I discuss more with the parties this potentially impacts this list may grow a bit - but that is a first blush at what would be required to do what you want.

@ph1ps I claim that any destruction of the Never vs any Error throwing case is a non starter for pretty much all algorithms. We have focused a lot of effort to ensure that any non throwing sequence should never require a try for iteration. Any place that doesn't happen it is a destruction of user expectation - so thank you for catching that nuance.

Generally speaking for anyone looking in the future for back ports of things - the bar is REALLY high in pretty much all maintained packages so this should NOT be viewed as a precedent to justify other back ports - they each have to be considered in their own merit, impact, and fallout (it really does pose a lot of complications for maintaining and delivering packages that are blessed as part of the Apple open source side of things and likewise for the Swift core libraries and even more so for the Swift compiler set of targets).

Additional tasks that would be extra bonus round stuff:

• Updates to the pitch/documentation
• Example code in the documentation showing how it is expected to work on pre 6.2

These are not hard requirements for the author to specifically do but anyone who can pitch in that will definitely make my life easier ;)

Hello, I've tried to update this concept with your suggestions (I completely missed the "forced throw" thing, thank you for catching it).

I've been diving into the matter of this "backportable Failure" for a while, ending up on the forums where the idea seems to be to add a second protocol with a "new" Failure associatedtype. There seems to be some concerns by Slava Pestov about mangled names in distributed libraries (our case), but this should not be our case because - if I understood it correctly - (AsyncAlgorithms,FailableAsyncSequence.Failure) will always follow (_Concurrency,AsyncSequence.Failure) in lexicographic order.

Also, I've set 1.1 to older iOS versions so that we could run tests in both scenarios (i've tried iOS 17.5 and macos 15, they are both working).

Any feedback is welcomed. Thanks.

Also, on top of that, I don't think we are going to need anything additional documentation for older versions, because it will work as expected - if the underlying sequence never throws, the .share()version won't as well. Otherwise, as with all other sequences, any Errorwill be thrown.

I think we can conditionally make it support typed throws, not just rethrows. Got a draft implementation working, but AFK right now. Will check back later tonight.

I think I've found a way as you said, but the iOS 17 crash is back. Will try again later

"Hic sunt leones" - at least for me.
I've created 1.2 version to allow 1.1 to be ported until ios 16 etc.
I understood where I was failing with the typed error and got it working, but now I'm constantly hitting a runtime error probably related to the missing next() declaration with isolation context on the AsyncIterator when I run tests on iOS 17.5 (it's available via extension only on 1.2).

If I move the next() method inside 1.1 everything works as expected but we lose the typed error on 1.2 (all errors becomes any Error)
At least it's better than forcing non-throwing sequences to handle non-existing errors like before, but still - if the point is to keep typed errors then we need something different.